ACK Flood即ACK Flood攻击。在TCP连接建立之后，所有的数据传输TCP报文都是带有ACK标志位的，主机在接收到一个带有ACK标志位的数据包的时候，需要检查该数据包所表示的连接四元组是否存在，如果存在则检查该数据包所表示的状态是否合法，然后再向应用层传递该数据包。如果在检查中发现该数据包不合法，例如该数据包所指向的目的端口在本机并未开放，则主机操作系统协议栈会回应RST包告诉对方此端口不存在。通常状态检测防火墙所做的事情与此类似，只不过防火墙只拦截非法的数据包，而不主动回应。

对比主机以及防火墙在接收到ACK报文和SYN报文时所做动作的复杂程度，显然ACK报文带来的负载要小得多。所以在实际环境中，只有当攻击程序每秒钟发送ACK报文的速率达到一定的程度，才能使主机和防火墙的负载有大的变化。当发包速率很大的时候，主机操作系统将耗费大量的精力接收报文、判断状态，同时要主动回应RST报文，正常的数据包就可能无法得到及时的处理。这时候客户端（以IE为例）的表现就是访问页面反应很慢，丢包率较高。但是状态检测的防火墙通过判断ACK报文的状态是否合法，借助其强大的硬件能力可以较为有效的过滤攻击报文。当然如果攻击流量非常大（特别是千兆线路上，我们曾经观察到200~300Mbps左右的ACK Flood），由于需要维护很大的连接状态表同时要检查数量巨大的ACK报文的状态，防火墙也会不堪重负导致全网瘫痪。

目前ACK Flood并没有成为攻击的主流，而通常是与其他攻击方式组合在一起使用。回顾前面描述的SYN Cookie算法，其核心思想是主动回应SYN/ACK包，然后校验第3次握手的ACK报文是否合法，目前大多数实现中校验ACK报文的合法性都涉及到较为复杂的算法。当SYN Flood与ACK Flood一起发生的时候， 主机和防火墙将耗费大量的精力来计算ACK报文是否合法以致不堪重负。

TCP/IP协议的特性以及数据传输特性中得到一定的统计规律。在现实世界中，正常数据传输的两个方向（客户端à服务器，服务器à客户端）上的报文数量基本上是均衡的，同时数据报文的内容是较为随机的。因此，当数据传输两个方向上的报文数量发生倾斜的时候，基本上可以判定发生了攻击。并且在大多数情况下，由于为了追求发包的速率，攻击报文的内容是较为固定的。因此，防护设备可以通过学习攻击报文的特征，当某个特征在一段时间的采样内大量重复出现，那么基本上可以判定符合此特征的数据报文为攻击报文。当然，统计的方法不可避免会带来误判，因此将统计方法与连接状态检测结合起来是比较合理的做法。